1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, apparatus, and products for link-level data communications.
2. Description of Related Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely complicated devices. Today's computers are much more sophisticated than early systems such as the EDVAC. Computer systems typically include a combination of hardware and software components, application programs, operating systems, processors, buses, memory, input/output devices, and so on. As advances in semiconductor processing and computer architecture push the performance of the computer higher and higher, more sophisticated computer architectures have evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
In a modular computer chassis multiple modular computer systems are connected to one or more switches for their network connectivity. Typically in these systems, each application network port of a modular computer system connects to a modular switch. Multiple application ports from a single modular computer system generally each connect to separate modular switches. Generally these individual switches each connect to different sets of networks. However, NIC teaming may be used where two of the switches connect to the same network and thus the associated two application ports functioning in a NIC teaming mode are connected to the same network through these switches. Either way there is an affinity between each application port and the network(s) to which its corresponding switch is connected. This rigid affinity limits the connectivity of application ports and can restrict the bandwidth between an application port and the networks to which it is connected via its connected switch.
Prior art has attempted to solve this problem by switch stacking With switch stacking Inter-Switch Links (ISL) are used between all these switches along with stacking protocols creating a single logical switch between the connected application ports and connected networks on this stacked switch. The ISL links carry both stacking protocols, which create the single switch image, and data from (to) an application ports to (from) networks. This data traffic across the ISL links is caused by application port data traffic to (from) a network which is not connected to the same switch as the application port. Although this structure solves the connectivity between application ports and networks, it can generate substantial ISL traffic to the point that the ISL links become a bandwidth bottleneck. Additionally, the stacked switch may support Link Aggregation Groups (LAG) across the individual switches to a network. With more than two links in the LAG, a better bandwidth and reliability model is created. However this does not resolve the traffic demand on the ISL links. Additionally, there is even more bandwidth demand on these ISL links in various failure conditions.
Further, one of the areas that has seen substantial improvement is data communications through packet switching. Today many systems provide processing of data communications packets that is transparent to the operations of the source computer, the sender, and the destination of the packets. That is, neither the source nor the ultimate destination of the packets is ever made aware that such transparent processing occurs. Such transparent processing may include for example security processing, load balancing functions among data communications equipment, statistical surveys, and so on. Such transparent processing can include processing by not just one, but several interim service applications, one providing security services, another performing statistical surveys, another performing load balancing, and so on. In a modular system, it is desirable to perform this transparent processing between the connected networks and terminating applications on the modular computer systems.
When data packets are to be processed by several service applications the problem of routing the data stream from one service application to another naturally arises. For service applications that carry out packet analysis and therefore operate in ‘bump-in-the-wire promiscuous mode,’ that is, transparently and invisibly sitting between devices on networks and terminating applications listening to all packets exchanged between the devices, preserving the packet headers is required. Because such service applications commonly perform inspection on the packet headers and the payload, the entire packet—payload+headers—must be considered “payload” to this kind of service application. Each such bump-in-the-wire service application must return each packet it handles to the communications system with the original header addresses intact so as not to interfere with the overall transmission of the packet from its original source to its ultimate destination.
Prior art has attempted to solve this problem by encapsulating the entire packet—payload+headers—and wrapping it with a new header that specifies the routing of the packet to bump-in-the-wire applications. This new encapsulation header must be understood by all the various hardware, switches, NICs, and so on, and potentially even by the bump-in-the-wire service applications themselves. This requirement to process this additional layer of headers is a burden to hardware developers and application providers who must now design, develop, test, and support an additional configuration of their core product. In addition, some solutions require that application providers not only integrate new header processing, but also port their application to specific hardware and operating system platforms.
Another solution attempted in prior art was to modify packets in certain ways, such as changing the destination MAC address, for example. This option changes the packet and limits the ability to perform the types of analysis that rely on possession of the original addresses in the packet. Moreover, this solution requires hardware developers to provide additional modifications of routers, bridges, and switches that use it to track the original addresses and return them to the packets upon return from the bump-in-the-wire service applications.